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ABSTRACT 


Each planetary nlaalon requires a complex space vehicle which Integrates several functions to accoaiplish the 
mission and science objectives. A Mars Rover Is one of these vehicles, and extends the normal spacecraft 
functionality with two additional functions: surface mobility and sample acquisition. 

This paper assembles all functions Into a hiararchical and structured format to understand the complexities 
of Interactions between functions during different mission times. It can graphically show data flow between 
functions, and most importantly, the necessary control flow to avoid unambiguous results. 

Diagrams are presented organizing the functions into a structured, block format where each block represents 
a major function at the system level. As such, there are six (6) blocks representing Telecomm, Power, 
Thermal, Science, Mobility and Sampling under a supervisory block colled Data Management/Executive. Each 
block la a simple collection of atate machines arranged Into a hierarchical order very cloae to the HASREM 
mcyiel for Telerobotics. 

Each layer within a block represents a level of control for ■ set of state machines that do the three 
primary interface functions: Command, Telemetry, Fault Protection. This latter function Is expanded to 
Include automatic reactions to the environsient as well as internal faults. 

Lastly diagrams are presented that trace the aystem operations Involved In moving from site to site after 
site selection. The diagrams clearly Illustrate both the data and control flows. They also Illustrate Inter- 
block data transfers and a hierarchical approach to fault protection. This systems architecture can be used 
to determine functional requirements, interface specifications and be used as a mechanism for grouping 
subsystems (I.e., collecting groups of machines jor blocks consistent with good and testable 
Implementations). 


1. INTRODUCTION 

The history of operational planetary rovers begins with the USSR Lunokhod-1 mission on the moon, a nearly one 
year mission beginning in November, 1970. The Lunokhods were interactively controlled, starting and stopping 
according to planned sequences created by a ground mission team receiving TV images. 

An advancement on this design principle Is the JPL»s Computer-Aided Remote Driving or (CARD) system 
implemented on a six-wheeled test vehicle. This system was developed under sponsorship of the U.8. Army Tank- 
Automotive command and demonstrated the capability of on-board execution of a human operator selected path drawn 
on a frozen image of the local terrain (Reference 8). 

Current rover concepts vary from advanced concepts of this design (CARD) to highly automated vehicles 
performing automatic collision avoidance (for example, JPL's Semi autonomous Navigation or (SAN), Reference 1). 
Unlike the Lunokhods, concepts under study for a Mars rover mission (Reference 9) must accommodate in- situ 
sampling, very much like an automated geologist. This complexity dictates a flexible systems architecture 
invariant to different levels of automation. 

Because of the nature of the mission, the architecture must combine the functionality of planetary spacecraft 
with the additional functions of mobility and sampling. Inclusion of these last two major functions 
dramatically expands traditionally layered architectural structures for spacecraft systems. 

An architecture which incorporates a mobility function, must provide a structure for accommodating simple to 
complex walkers as well as the more traditional wheeled carriage vehicles. One of the simplest walker concepts 
is Brooks* 1 kg rover consisting of fifty-six (56) state machines cycled individually In a particular pattern to 
produce a "gait** (Reference 2). A more complex walker concept Is the Carnegie Mellon University "ambler" 
(Reference 3). In between may be considered the elegant "beam" walker concept of Martin Marietta Cor^ration 
(Reference 4). In each case, a multi-layered architectural structure Is suggested where control of individual 
walker link motors or wheels are coordinated at higher levels to produce the desired motions. 


The addition of a sampling function introduces the added complexity of control of manipulations. As recent 



the sampling function. But later manned missions, with associated human Interaction with the rover, require 
consideration of a range of supervisory control options for the sampling function. Consequently, human 
interactions must be smoothly Integrated into a control architecture for the rover. 
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In this paper, a single architectural concept integrating all of the above is proposed for the general class 
f planetary rover concepts in the 1990's. The architecture is a loosely coupled, state machine conc^t 

control concepts of NASREH (MASA/MBS Standard Reference Model for Telerohot 


Control System Archi tectures. Reference 5). 


The following describes the architectural concept and provides a mobility scenario, tracing the sequential 

Ze f’r TV*‘ "^^"i lecture. A sampling scenario has ZZeen 

done for completeness but is not presented here for the sake of brevity. Both scenarios validate the 
architecture's flexibility and accuracy. 

some final thoughts are presented on the uses of the architecture. These observations should apply to 
any good architecture, not just this one. For example, a typical systems design task is the mapping Tf ^the 
system functions into an implementntion by a number of subsystems, defining boundary interfaces at simple 
junctions <e.g.. functional levels). This architecture naturally decomposes into the standard subsystems for 
planetary spacecraft and provides a structure for the evaluation of alternate decompositions. ^ 

2. PLAME7AKY NISSICHIS 

Before discussing details of the architecture, we introduce some of the basic functions and subsystems of anv 
planetary spacecraft, A Hars Rover, after all, is at least a planetary spacecraft and much more ^ 

Basic subsystems of any planetary spacecraft include Telecommunication, Power. Thermal, Attitude Control and 
subsystems are three activities: receipt and/or processing of commands, telemetry 


No planetary spacecraft has been designed to be fully autonomous. Instead, these spacecraft are seml- 
the sense of the above discussion), relying heavily on ground control for mission commanding, 
analysis, and planning. Therefore, any general architecture for spacecraft control will include a significant 
fu'^ctions may move from the ground to the spacecraft if more risk Is assumed or capability made 
available. An example of this enabled the extended Viking mission. After the primary mission and with suitable 
confidence in the spacecraft capability, the Viking program reduced Its operational ground staff significantly 
by reprogramming the flight computers on the arbiters with automatic routines for fault protection. 


subsystems are Hobility and Sampling. Mobility contains the local navigation 
!“?!!!!?.- traverse. This local navigation function is very Important, requiring 


interactions among other functions. Some architectures for a rover represent only this viewpoint. For ™Je® 
Kovtunenko (Reference 6) represents the local navigation function as the main interface to the Earth and central 
o?her major describing control principles, but neglects 


NRSR MISSION 


A HRSR mission has many variations (including some without a separate rover vehicle) The follnuinn ci imma. j 
main mission and operational requirements for a rover in the MRSR mission? following summarizes 

r"''*'' "'■'••'y ‘|’« "‘'"'ber and types of samples which can be returned from Hars (Reference 7) A 
nMinal rover operation entails a sequence of local traversing segments and sampling, constrained by on-board 
itm?^ Z tround interactions. Prolonged or extensive decision time by the ground operations can severMy 
limit the rover’s integrated range (from a goal of 40 km-lOO km). ^ 


PiZ. *^*1 *'’i® .P'P®''' consider that each traverse segment is using semi -autonomous navigation. 

Figure 3 1 Is a functional diagram of the activities. At a certain point, the ground up>tinks a toDoaraohlc m«n 
fr^ a ground-based Global Route Planner. This map contains a first-order ground swath for the ?oJZr?rS!^Z 
and a designated path(s) avoiding obstacles and dead-ends that remains scientifically interesting. 

• Ponocoie'c view of the local scene using stereo cameras, laser scanning, or structured light 
linked to machine vision and image processing functions. The rover computes a local map from the processed view 
thf Mtch** portion of the global topographic map sent from Earth. Using the results of 

the match, constraints of previous rover positions and output of any other navigational devices the rover 

Z'r^vZ/ln" rrr“** Z'**'’:.'’! / »*P *• formed from the two sZees (gr'oJiXglZI 

Z.ZriL ’ to produce a high resolution map in the vicinity. A new path then is computed v a simulation 
revising the approximate path sent from Earth by including (and thus excluding from the ^sth) small obslaclei 
not detected by the low resolution images of the global map. The original global resolution is required to be 
accurate to 1 meter. The fused map could be accurate to 10cm. The rover then traverses the path. 

..Zf.'.Tl'."® T*!!' of the path is used to compute slope changes and tilt 

expectations. These are used in a predictive way to set limits on inclinometer and local proximity sensors 
These predictions control the rover's reflex actions in the event on errant path is followed. 
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FIGURE 3-1 
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If enough computational resources exist, the cycle of global map up-Unk(as needed) - fused map development- 
path planning - traverse can be repeated every few minutes, for a resultant average speed of lOcm/sec (see 
Reference 1). Typically a local path is computed for about thirty (30) meters, with the rover pausing every ten 
(10) meters or so to re-evaluate its condition. 

4. NASREN 

NASREM is a standard telerobotic architecture now adopted by the FTS, its contractors and many others 
associated with the Space Station program (Reference 5). 

The NASREH is a modular, hierarchical conceptual architecture for telerobotic system control (see Figure A-1). 
The main feature of NASREH are six layers of control: 

(0) the world: hardware elements, being controlled by the telerobot and the environment of operation 

(1) the servo level: coordinates are transformed and outputs servo the arms/end-effectors 

(2) the primitive level: telerobot dynamics are computed and coordinated arm commands issued 

(3) the E-move level: obstacles (including those inherent to nrm operation) are observed and commands issued 

to avoid them 

(4) the task level: tasks to be performed on objects are transformed into movements of effectors 

(5) the service bay level: task on groups of objects In the vicinity of the telerobot are sequenced and 

scheduled 

(6) the mission level: objects are collected into groups, resources are assigned between telerobots and 
parts/tools are routed and scheduled 

Each NASREM layer is partitioned into three modules: sensory processing, world modeling and task 

decomposition. Additional features Include a global memory to support the flow of Information and coordination 
between levels In the hierarchy and an operator interface to support operator input and display capabilities at 
all levels of the hierarchy. 

Since the control levels are well ordered, unambiguous commands flow from the top of the hierarchy down to the 
lowest level of the servomechanism. This is role of the task decomposition elements of the architecture. At 
each level in task decomposition, a job assignment manager partitions task commands into distinct jobs to be 
performed by one or more planner/executor modules. As such, each planner is responsible for decomposing a Job 
command into a temporal sequence of planned subtasks. The executor evaluates the sequence prior to execution. 

Data or status flows in reverse from the lowest levels of the hierarchy to the top levels. This data Is 
available from three sources. The data may be fed back from one level to the next through the hierarchy in task 
decomposition. Alternately, depending on the use/need, the data may be read from the global memory. This global 
memory is a data base where knowledge about the state of the task space, task environment and Internal state of 
control system Is stored. Each layer of the hierarchy and all processing modules within a layer contribute to 
global memory. Lastly, data may be received through the interaction of the telerobot system with the 
environment. This data is obtained through the sensory processing elements of the architecture. Sensor 
information is read and processed in a hierarchy which allows the system to recognize patterns, detect events 
filter and integrate information over space and time. * 

The processing of the data or status is performed using models of the effectors, sensors or environment of the 
telerobot. This is the role of the world model elements of the architecture. These models include estimates and 
evaluations of the history, current state and possible future state of the telerobot system and task space. 
These models help maintain the data in global memory, offering confidence levels/statlstics of model predictors 
and sensory observation. 

The last elements of the architecture are contained in the operator interface. The functions In these elements 
enable Interface to each level of the hierarchy. The operator can enter the control flow to monitor a process, 
insert information, interrupt automatic operation, take over, and apply human intelligence to the processing! 
Feedback ranges from force reflection at the lowest levels to displays for interactive scheduling at the highest 
levels. 


In guiding functional part i t ioning, this architecture constrains functions to a given layer by processing rate 
or bandwidth. At the lowest levels, the processing is severely time dependent in stabilizing servo control 
loops. As such, rates of execution may be as high as 1000 times per second (or 1000Hz). At each higher level the 
rates decrease generally by a factor of 10 or more. 


In Implementing the architecture, the available technology and operational priorities dictate additional 
constraints. The processing load at the lowest levels lead to optimization of communication paths. Thus, the 
data in global memory which serves inter-process communication at these levels may be kept separate from data at 
other levels, with access prioritized by need for the control loops. The need for verification of command 
sequences at the higher levels of the architecture lead to the inclusion of simplified (though correct) models 
of specific hardware in the world models at these levels. 

5. ROVER SYSTEM ARCHITECTURE 



In considering then the definition of a NASREN model for use In a rover system, we utilize the concent of 
small state machines introduced by Brooks (Reference 2). Level 1 functions can simply be interpreted as those 
state machines which implement the settings of dynamical systems or the states to be controlled. In the Brooks* 
walker, these states are the different positions of the legs. In the control of a robotic arm the states are the 
various settings of the joints of the arm. Level 2 functions set permissible states as represented by a control 
law, constrained by various dynamic and kinematic models. At the next level, a sequence or function of 
permissible states implements a subtask or operational process for the rover. At this level for example the 
movement of a walker along a path is a sequential execution of repositions, with each reposition itself a 
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sequence of leg motions in a controlled, coordinated (or gaited) move. For an arm, a cartesian-space referenced 
path is achieved by moving the arm joints to achieve a series of end-points. Task planning at the highest level 
generates collections of sequences which accomplish a task. For example, movement of an arm or rover from point 
A to B is achieved by the execution of a set of commanded path segments. 

Figure 5-1 is a generalized version of the MASREM model where this new state-definition terminology is 
applied. In another change from Figure A-1, we have re-ordered the columns adding a slice so that a distinction 
is made between world models of the environment being sensed and world models of devices being commanded. The 
global data base becomes the middle slice and contains the constants and parameters of the world models as well 
as the data comprising the state of the overall system. 

To the functional processing machines, we have added a third dimension to the architecture: a stack of command 
and a stack of telemetry machines. Commands flow down and telemetry flows up. In between is a separate stack 
of fault protection machines which can be excited and alter commands and telemetry at any given time. Fault 
protection machines execute as a result of a detected error read through telemetry. They implement recovery 
actions through commanding of the functional processing elements to assume a new state. As an example for a 
mobility subsystem, on inclinometer may sense an excess tilt angle, A corresponding fault protection machine 
will detect the error based on the telemetry and then act by issuing a command to cease forward motion. In 
addition, an appropriate routine may be executed such as carefully retracing the last series of commands until 
acceptable tilt angles are achieved (i.e., back-up). Once completed and the vehicle is safed, a route replanning 
will be commanded. 

Notice that In the above example conmand and telemetry machines interact with the fault protection machines 
The fault protection machine orchestrates the actions of the functional processing machine(s) implementing 
recovery. In detail then for the above example, an inclinometer at Level 1 registers excessive tilt causing a 
Level 1 fault machine to interrupt commands from Level 2 thereby halting the system. Telemetry is then sent to 
the Level 4 fault machines which have been receiving some subset of the last successfully comnanded states. The 
Level 4 fault machine then calls for the task execution of a traverse back to a point along the route. Coinmands 
then flow normally downward until this previous state is achieved. When this happens, system control is then 
passed back to the task planner which knows its path plan has been altered and must replan a new path, which has 
a prescribed set of greater margins of expected tilt angles along its simulated path. 

If any of these actions require more power or other subsystem intervention, then there is data flow between 
subsystem. Each such subsystem is represented by a block as shown In Figure 5-2. This is the fourth dimension of 
the architecture. 

Returning to the basic functions of a spacecraft, we can now construct the entire model of a Hars Rover (see 
Figure 5-2). It consists of seven "cubes" in all. The Data Management System is an automated version of the 
Command Data System, complete with a tasking level. Each element is a state machine, so there are 560 state 
machines not counting the world elements at the bottom. Notice this is exactly ten (10) times the 56 machines 
of the insert Brooks' walker. Furthermore, each small machine is considerably more complex. 

There are some interesting features of this architecture. For example, the front faces all represent the 
control while the sides are data flow. This gives one a complete look at the total Information system 

during the design process. Also, it is important to note the information flows between blocks. This is 
accomplished using the global memory of each face of each block. The four dimensional property of the 
architecture allows a an arrangement which make communication possible among the global memory (i.e, global 
memory of the system architecture is a 'block* cross-section of the four dimensional 'cube'). ' 

There is much information being exchanged between the Data Management System block and the other subsystem 
blocks. Also note that data from the ground first appears in the Telecommunications block and then to Data 
Management. Data Management controls the other blocks through its commanding sequence in order to accomplish a 


As an e«mple of a planetary spacecraft viewed in this architecture. Voyager's task planning was a function of 
the ground mission control teem. Its Data Management System is the CCS or Command & Control Subsystem Its 
command and control functions can be mapped to the lower two (2) levels of the DMS architecture (see Figure 5- 
3). The mobility function (Figure 5-8) degenerates to a three level Attitude A Control Subsystem. Sampling 
disappears altogether. In this architecture the Voyager FOS (Flight Data System) is the sum of all the 
telemetry state machines. The Science block contains the commanding of the science platform, which mav be 
represented in a single level architecture. ^ 

The Fault Protection Subsystem for Voyager consisted of automatic recovery routines; little on-board tasking 
based on sensory information was allowed. Therefore we at once con write down the totality of the Voyager 
Figure 5*2 Protection system as the sum of the Fault Protection slices up to level 3. This sum is given In 

We wish to esiphasize that all parts of the blocks exist on Voyager and only certain levels were flown The 
rema ning levels for Voyager were all on the ground. As spacecraft become more automated, functions ind/or 
levels can be transferred to the spacecraft. These trade-offs are not always implemented since a degree of risk 
is incurred by this transfer. 

The current concept of the Rover has more of these functions on-board than standard planetary spacecraft. In 
this case, increased on-board autonomy not only reduces ground operations but increases range and (thereby) 
science measurably. 

The remaining Figures 5-3 through 5-9 round out the complete architecture. Notice that some state machines 
are inoperative, a reflection of today's level of conceptual design. In most cases, however, these state 
machines are simply not needed (see e.g.. Thermal above level 1 in Figure 5-6). 

In order to penetrate the design further, the following section will focus on the mobility block which 
contains the local navigation function. As we mentioned earlier, this is so impurtant to the rover designers 
that they often view the world as a large mobility block supported by other subsystems. 
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The mobility block is shown in Figure 5-8. The highest level is focused on the task of developing then 
utiliiing a local terrain map in route planning as the discussed under Section 3. After a 30 meter planned path 
is selected the vehicle can begin to roll. The rover executes this 30 meters 10 meters at a^time %he 
execution of this 10 meter traverse is detailed below. 


In this section we will give an example of an operation of the rover vehicle and the accommodation provided by 
the functional architecture. In this operation, a command has been received by the rover from the mission team 
to move to a new location, based on the transmitted views of the site. The rover system must evaluate the 


rover system to determine the end of the operation as well as to proceed within available resources and within 
limits of safe operation. 

In summary fashion the steps executed by the rover system in accomplishing the traverse include; 

(1) tasks performed by the ground support team in determining the new location for the rover 

(2) the up- 1 ink and 

(3) on-board processing of command sequences which result in receipt by the rover of new goal state 

(4) the determination of a feasible route to the goal state by the rover system 

(5) the planning necessary to determine a route 

(6) the execution of a traverse along the planned route. 

In performing these steps several subsystems within the architecture interact to execute the required 
functions. Particular capabilities of these subsystems in accomplishing these functions are identified In 
summary fashion; m 


EXECUTIVE; sequencing of subsystem support in the determination of a feasible route; 

col tect ion/evatuat ion of periodic reports of progress during execution of the tr 
final acceptance of reaching of the goal state 

TELECOMHUNICATION; 

commutat ion and de-commutat ion of commands and telemetry 

POWER; determination of available power resources in support to route planning 

MOBILITT: provide imaging data of the near vicinity of the rover; 

perform route planning; 

execute rover movements which effect the traverse along the route 
SCIENCE: provide instrument data products which support evaluation of the site 


The following is a detailed discussion of the example of execution of a traverse. The flow of activity follows 
the exploded' pictorial representation of the subsystems given in Figures 6-1 to 6-4 . Interspersed in the 
discussion is bracketed <[...]) references to specific steps shown as a flow of activity in the architecture on 
these Tigures. 


6.1 GOAL DEFINITION 


The mission science team evaluates the latest data concerning the geological and mineralogical properties of 
surrounding the rover. This data is a compilation of over-flight imaging taken by the companion 
orbiter, data available from past missions (e.g.. Viking), observations by the on-board rover science 
instruments (possibly an imaging spectrometer and sounder), end range and feature data provided by the imaging 
components of the on-board rover mobility system. A new location (or set of locations) of interest is selected 
and registered «» ® of) mission objective. In this example a location 10m from the current site of the 

vehicle is identified (la of Figure 6-1]. 

The vehicle team in mission control evaluates the selected locations based on models of (recent) past rover 
performance. An evaluation of feasibility in terms of vehicle health state and resource availability is 
performed [1b of Figure 6-1). Simulations of the vehicle traverse over the terrain (available from over-flight 
and on-board rover imaging) assist in providing the feasibility check [interactive loop of Figure 6-1 between 
world model and task decomposition at the Hission Planning level of the executive). A recommendation is provided 
to a mission director [the mission planner of task decomposition at the Mission Planning level of Figure 6-1) 
who in turn weighs the science return/object ive(s) against the vehicle utilization. Conflicts (if any) are 
resolved and a new location (or set of locations) are identified for the rover [1c of Figure 6-11. 

6.2 UP-LINK 

The new location (in an appropriate inertial frame) along with related route inforiaotion, including the 
expected length of the traverse (lime, distance) and points of interest along the route (for collateral imaging 
and science instrument observation), is passed to Telecommunicatior.s for encoding I2a of Figure 6-Z) 
com^tation and up link transmission (2b of Figure 6-21. (M.B., These steps are performed by a separate though 
similar Telecommunications subsystem located on earth. For purposes of illustration these steps are shown on 
F I gure 6 - 2 . ] 


In addition, appropriate support data is commanded to other systems which will provide the latest update tc 
he rover. This includes a topographic map generated as a result of over-flight by the planetary orbiter and « 
ew reference location in inertial space for the rover developed by interferometry from tracking data 
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6.3 RECEIVE COMMAND 

Th. DosIHon and associated data are received through Telecommunications. The data is de-commutated 

[3a^ of figure 6-*2] , decoded [3b of Figure 6-21 and stored [through the use of t^ global 

the subsystems) for use in subsequent operations (3c in figure command and associated constraint , 

and 3c in Figure 6-3 for the topographic map and reference location). 


6.4 


ROUTE PLANNING 


an expected 
using the 
to Mobility 


The receiDt of a cofliraand for a traverse to a nea location at the Executive I3c of figure 6-1] begins a 
niannina act^lvltv whlch leads to the generation of a feasible route. The executive colls upon the subsystexis [*a 
SI nguVbViV t^ Jlporl thl cur^^^^^^ of resource, available for the traverse I6c 

«tafu. renorts becoiae a Dart of the constraint space used by the route planning function I4a of Figure 6 '!• * 
^l^p^r^on o^tlH^ fu'ITctlon Is located In the Mobility subsyste- [Figure 6-31 He« the current *««»• «<a a 
gathered froia the liaaging systems on-board the rover are evaluated against the models of the terrain to 
dJJemlne thJ route to the ?.ew location (see 6.4.1 below). Once the route Is BenerMted (with a 

resource utilization) a final go/no go evaluation Is P*''*":"*** Ij** '^'“‘•'''fr^ the exMutWe t 
data In any subsystem or other reports received during route planning. A go from the executive t 

begins the traverse to the new location. 

6.4,1 MOBILITY: ROUTE PLANNING 

Route planning begins with the gathering of the latest imaging data of the site surrounding *b» present 

portion of the rove?. A panoramic view of the site is developed through the execution of • ^^^e ?u??e?t 

(for example) a pan and tilt mounted camera system on the rover. The precise sequeiwe, based on ^be current 
vehicle state Is'^ developed (at the task planning level of Mobility) and commended for execution (5a(i) of 
Figure 6-3) The commands, initially in inertial coordinates, are transformed into specific motor drive commands 

«Th. motVr .iech^a^^^^^ camera system [the hierarchical flow of com^nds ‘brough th i , , 

th* Hobmtv subsystem, labelled 5a(i)). At each position in the sequence, an image pair (for stereo) is 

captured and digitized for further processing l5o(iI) of f igure 6-31 . The ^ 

correlation of multiple images and image processing result in developing range and dimension of specific 

features [5a(iii) of Figure 6-31. A correlation of image features to models of terrain features <e.g., boulders, 
ravine^ across several image pairs results in a list of position- and di mens ion- registered objects (or 

obstaclL) for use In route planning [5a(iv) of Figure 6-31. A final correlation to an 
allows computation of rover position in the terrain and a selection (based on the commanded new 
por?ion o7the m^^^^ use by the route planner [5a(v) of Figure 6-31. These results are stored (in the global 
data base! in the^ form of a fused map of the route locale of greater resolution than available from the up- 
linked topographic map alone for use in subsequent route planning. 

The route planner generates a path to the goal state (the commanded location of the rover) which 
intermediate^view point criteria (if any), the vehicle physical constraints th# 

and local obstacle avoidance [5b of Figure 6-31. As part of the verification of the suitability the P*thg the 
movement of the vehicle in the terrain is simulated. In addition, during the simulation expectation models of 
vehicle performance are generated for use in monitoring the actual traverse of the rover along the path [5c of 
Figure 6-3). Only a portion of the planned path is slated for execution, as the 

function of range. In the case of goal of 10m nominally the entire path can be executed. A report to this effect 
is generated for final go/no go disposition by the executive [5d of Figure 6-31. 

6.5 MOBILITY: PATH TRAVERSE 

The planned path is executed in Mobility upon receiving a go ahead command [6a of Figure 6-4). The 
path in inertial coordinates is transformed into vehicle coordinates t6a(i) of Figure 6-4), specific coordinated 
moves and turns by the vehicle carriage [6a(ii) of Figure 6-4] and servo commands to the motors [6a(lii> of 
Figure 6-41 . 


Each command type represents the output command of different type of control law used in the execution of 
vehicle motion. At the lowest level [State Level of Mobility] . loop is closed aroiw^ ‘"f/Vh-® n^*"l ! 
the feedback from motor encoders [6b(i) and the innermost loop A In Figure 6-4] . At J 
heading/dead reckoning loop is closed around the turn or move commands as measured through the feedback of 
gyros/IMU or coxipass I6b{il) and loop B in Figure 6-4]. A control loop arou^ the VA",?, ! 
closed through feedback measurements from accelerometers and over-the-ground sensor ^ 

Figure 6-4). A final control loop is centered around the constraint of provid ng a stable platform during the 
traverse. The feedback for this loop is provided by inclinometer and integration of the readouts of gyros/IMU 
[6b(iv) and loop D of Figure 6-41. Each loop stores feedback data, commands and state estimates for evaluation 
of vehicle performance during the traverse. 

other processing during the traverse monitors and performs the vehicle state evaluation based on the P'-ogress 
reported by lower levels of the hierarchy. In particular, the progress of the traverse Is compared age nst the 
model of performance along the path. Corrections in the form of commanded turns and moves ensure compliance to 
way point and obstacle avoidance constraints [6c of Figure 6-4). Lastly, progress to the goal state is monitored 
with periodic reports issued to the executive [6d of Figure 6-4 and Figure 6-11. A final report of reaching the 
new location ends the traverse and monitoring loop in the executive. 

7. UTILITY AMO APPLICATION 

The architecture as it is laid out forms the basis of a complete Rover Architecture. When completed it should 
ntain all of the functions both on the ground and in flight. It is at once a complete description of both the 
ntrol and information flows. Step by step sequences and loops can be worked out for various strategies so the 
signer can see the interface complexities directly. 

Evaluating the rate of execution of these loops can aid in identifying technology alternatives to achieve a 
greater mission capability. As was discussed at the end of section 4. execution rate Is one factor in 
determining where functions sit in the architecture. If a mission planner wishes to increase the range of the 
rover, more functions must be 'pushed further down' in the hierarchy or greater processing technology brought to 
bear to achieve the required performance. 
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In addition to basic design strategies, detailed fault protection scenarios can be worked out. 
making sure control loops are continuous and unbroken. Often, in fault protection design the 
required elements of the design are difficult to identify. This architecture shows that a fault 
protection machine must be considered for each state machine in each subsystem. The architecture 
aids in identifying communication paths (commands and telemetry) needed to achieve the fault 
protection capabi I ity. Tracing scenarios of recovery (as was done in section 5 in brief) reveal 
the cofiMnun I cat ion paths required* 

Finally, by computerizing this model, representing each state machine by the convention 
for each element and Including these elements In a data base, control loops can be easily 

execution of elements. Strings repeatedly used In these control loops can 
be Identified and represent the state machines which must be developed and tested first. 

6. OONaUSlON 

concept for a planetary rover Is presented, based on an expansion of 
the NASREM concept for telerobotic control, A mapping of this architecture with the functions 
In a MRSR mission has been performed. An example of a mobility scenario executed 
^ architecture va 1 1 dates the concept. This example and associated discussion Illus- 
trate the capability of the architecture to serve as a tool for design and functional trade-off 
ana i ys i s . 


a carried out by the Jet Propulsion Laboratory, 
California Institute of Technology, under a contract with the Office of Aeronautics and Space 
Technology, National Aeronautics and Space Administration. 
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